home *** CD-ROM | disk | FTP | other *** search
- Path: newsfeed.internetmci.com!xmission!news
- From: tknarr@xmission.com ( Todd Knarr )
- Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.edu,comp.lang.c,comp.lang.c++,comp.lang.modula2,comp.lang.modula3
- Subject: Re: Hungarian notation
- Date: 12 Jan 1996 02:11:27 GMT
- Organization: Chaos Central
- Message-ID: <4d4g0f$qmr@news.xmission.com>
- References: <30C40F77.53B5@swsbbs.com> <30EF0415.6FE1@tus.ssi1.com> <1996Jan7.045815.8676@ohstpy> <4cpb00$nqk@news.xmission.com> <4crm6i$24mi@navajo.gate.net> <4csi2t$gsa@news.xmission.com> <4ctomq$1pi8@hopi.gate.net> <4cvhga$5rn@news.xmission.com> <4d31ne$2m6@hopi.gate.net>
- Reply-To: tknarr@xmission.com ( Todd Knarr )
- NNTP-Posting-Host: slc5.xmission.com
- X-Newsreader: IBM NewsReader/2 v1.2
-
- In <4d31ne$2m6@hopi.gate.net>, feathers@gate.net (Michael Feathers) writes:
- >Funny enough, even in the absence of HN it seems that there would still
- >be a problem. Someone would look at the declaration of the reference
- >and see that "ambiguous" type and could very well be decieved. Frankly,
-
- As I said, the problem comes only when they believe the promise that the
- HN prefix makes. If you're going to ignore that promise on all variables,
- why bother making it in the first place? Absent the HN prefix, anyone
- looking at the code will automatically look back to the declaration to
- find the type, and my automatic reflex when I see a pointer or reference
- type in C++ is to check the class heirarchy. If I believe the HN prefix,
- I don't have a reason to check the declaration, I won't see the reference
- typing, and I won't get reminded to check the heirarchy before assuming
- that it's really the type claimed. Pointers are more obvious, but HN is
- still making a promise that a pointer to Stall is a pointer to Stall and
- not a pointer to OfflineStall so the potential for believing the promise
- is still there.
-
- Leaving the HN off won't guarantee the programmer will check, but at least
- it doesn't give him an excuse to cry "But the name *said* it wasn't an
- OfflineStall!". It's the same as with misleading comments. The idea of a
- comment is to tell you what the code is supposed to be doing without first
- having to decipher it in detail. If you have to assume the comments are
- wrong and decipher the code in detail anyway, are the comments really
- doing any good?
-
- >I don't really get the problem. If your derived Stalls are true
- >specializations of the Stall concept, then there are certain operations
- >which apply to all Stalls and there are operations which apply only to
- >specific classes of stalls. The former should be in the base Stall class
- >and the latter in each of the derived classes.
-
- That is in fact the case. The Stall class defines the interface and certain
- "normal" behavior, and each subclass alters some portions of that behavior
- as needed. The problem comes when someone else comes along to do maintenance
- on the code. They know what they want to have happen, the question is what
- part of the code do they need to change to make it happen. If they read the
- detailed design and roadmap document they'll be fine no matter what, but
- if they begin by tracing the code to see where the action they want to
- change gets triggered ( easy enough, it's a very straight line to the one
- member function that handles that action ) then they'll find at that point
- that they are dealing with a reference to a Stall. If they have a reason to
- believe that, they would then obviously find that member function in the
- Stall class and modify it, neglecting to check the class heirarchy to see
- whether at that point that reference could be to some other derived class.
-
- >I may be wrong, but do you have services in your base Stall class which
- >would more appropriately be in a derived Stall class only?
-
- No, every service can be defined in some sensible way for the base class.
- Each subclass then alters some or all the behavior of some services to be
- appropriate to the particular type. In some cases the subclass must alter
- one part of the service for the whole to make sense, but each subclass
- alters a different part. For instance, if a particular subclass has to
- answer "Yes" to one or more of three questions, the base class answers
- "No" to all three and the subclasses only replace the one or ones that they
- need to answer "Yes" to.
-
- >There is alway RTTI. You could query and then downcast, but I've never
- >had to do that in practice.
-
- I dislike using RTTI for that. It smacks too much of type fields, and I
- generally don't need to know the type in the code that uses them. It's
- the guy who has to figure out where a change needs to be made, and in
- which class, that needs to know.
-
- >Truly, however, HN can work with polymorphism as long as the assumptions
- >of polymorphism aren't broken, and the prime assumption is that the methods
- >available for base classes have reasonable behavior for all derived classes
- >if you choose to pass around base class pointers and references.
-
- This speaks to use only. To use a class you only need to know the interface.
- However, suppose you have a List class that provides the interface and
- subclasses ArrayList and LinkedList that provide the implementation. You
- can use them without knowing which one you're dealing with readily enough.
- But, if one of them is causing segmentation violations, whoever has to go
- in and find and fix the bug bloody well has to know which *exact* class
- was being used at the time. If the segv occurred when comparing two Lists,
- he needs to know that it was two ArrayLists being compared via references
- to the base class or he may wind up trying to fix code that does not contain
- any bugs ( a rather frustrating excercise in futility ).
-
- --
- Todd Knarr : tknarr@xmission.com | finger for PGP public key
- | Member, USENET Cabal
-
- Seriously, I don't want to die just yet. I don't care how
- good-looking they are, I! don't! want! to! die!"
- -- Megazone ( UF1 )
-
-